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(57) A system for simulating a production environ- 
ment in which a plurality of components are subject to 
a plurality of different processes to generate an end 
product. The system comprises a plurality of modules, 
each module representing one of said processes and a 
set of data carriers, representing said components. 
Each module comprises read circuitry for reading data 
from a data carrier and means for providing an indication 
representing whether an attempted transaction of the 
module is valid or invalid. The validity or invalidity of the 
transaction is based on a predetermined job route which 
defines a valid predetermined sequence and timing of 
processes for each component or set of components. 
Each data carrier carries a unique identification which 
can be read by the read circuitry and which represents 
a component or a set of components. 
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Description 



The present invention relates to a system for simu- 
lating a production environment, and in particular an en- 
vironment in which a process flow can be divided into a 
number of distinct process steps. 

Managing the operation of a production unit or en- 
vironment effectively is a skilful and stressful enterprise. 
Strategic and tactical decisions must be made on a fre- 
quent basis and the consequences of such decisions 
may have an unseen and decisive impact on the oper- 
ation of the production unit. It would be useful if a man- 
ager could simulate the operation of his production unit 
so that the effect of a decision on the unit as a whole 
could be foreseen in simulation before the decision is 
made in real life. Systems intended to provide such a 
simulation are known, but they invariably involve a com- 
puter having dedicated software which has been spe- 
cially designed to simulate a particular process and can 
be extremely complex and expensive. Such machines 
may-be a justifiable expense in the petro-chemical or 
pharmaceutical industries but are prohibitively expen- 
sive for small-scale manufacturing industries. Moreover, 
it is not normally possible to make even simple changes 
to the software without going through a long, involved 
process. 

It would therefore be desirable to provide a system 
which is less complex and more flexible and which in 
particular can be easily adapted to simulate different 
process flows. Such a system would potentially have 
wide applications throughout industry and could bring 
the possibility of process simulation within the means of 
small companies. 

According to the present invention there is provided 
a system for simulating a production environment in 
which a plurality of different components are subject to 
a plurality of different processes to generate an end 
product, the system comprising: 

a plurality of modules, each module representing 
one of said processes and comprising read circuitry 
for reading data from a data carrier and means for 
providing an indication representing whether an at- 
tempted transaction of the module is valid or invalid 
based on a predetermined job route which defines 
a valid predetermined sequence and timing of proc- 
esses for each component or set of components; 
and 

a set of such data carriers representing said com- 
ponents and each carrying a unique identification 
which can be read by the read circuitry and which 
represents a component or a set of components. 

Modules can have local intelligence to establish val- 
id or invalid transactions on the basis of the job route 
which can be held at a database distributed across the 
modules. In this event, the modules must be electrically 
connected so that they can communicate. 



Alternatively the system comprises a controller 
which is connected to the modules, which can then be 
relatively "dumb- because the validity of attempted 
transactions can be determined at the controller. The job 
5 route can then be held in a memory local to the control- 
ler. 

Each module can have its own timer for monitoring 
the predetermined period associated with the process it 
is representing. Alternatively, the modules can commu- 
10 nicate with the controller in real time and the controller 
can determine the periods in simulated time and notify 
the modules accordingly. 

One advantage of a system according to the 
present invention is its flexibility. The system is not lim- 
*5 ited to the simulation of a particular process flow. Such 
flexibility allows the system to be used as a tool in the 
training of production managers. The system is particu- 
larly suitable for training managers in the taking of stra- 
tegic and tactical decisions under constraints of time, 
20 money, quality of goods, etc. Trainee managers can 
therefore develop an awareness of the problems related 
to managing a variety of interdependent but individual 
processes and develop the skills necessary to surmount 
such problems, without their training compromising the 
25 profitability of a real production unit. 

One feature of the present invention which makes 
it particularly suitable for training is the simulation of a 
process by a simple flexible physical model. This allows 
multiple users to be simultaneously actively involved in 
30 the simulation and encourages the development of in- 
terpersonal skills. It also means that extensive training 
is not required before a user may operate the simulation. 
Finally, the use of physical data carriers as representa- 
tions of the component inputs to and outputs from the 
as steps in the process allows a ready reckoning of where 
bottlenecks are occurring in the process. 

In a real production environment, each component 
or set of components would be occupied for a predeter- 
mined period associated with each process. According 
*o to one aspect of the present invention therefore it is pos- 
sible to allocate a locked status to the unique identifica- 
tion of a data carrier representing an occupied compo- 
nent when a valid transaction has been effected. 

The system can include a database holding each 
said unique identification in association with the type of 
component it represents and its current status. That da- 
tabase can be held at the controller or again can be part 
of a distributed database amongst several "intelligent- 
modules. 

50 Each module can comprise means for providing a 
visual indication of its status, such as idle, working or 
failed. This could be done on a LCD or by individual 
lights. 

The indication of a valid/non -valid transaction can 
55 be accomplished by a display or by an audible indicator, 
such as a b ep. 

The system can comprise a gateway module con- 
nected to the communication path of each module for 
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providing an interface between the modules and the 
controller. 

A system clock can be provided which provides a 
visual indication of simulated time in which said prede- 
termined periods are measured. The relationship be- 
tween simulated time and real time can be altered so 
that simulated time can be slowed down, speeded up or 
stopped altogether depending on the requirements of 
the simulation. 

The system can include an initiator for allocating to 
each module a process it is to represent. 

The initiator can also allocate to each unique iden- 
tification of a data carrier a component and a predeter- 
mined sequence of processes (job route) for that com- 
ponent type. 

Prelerably, the data carriers are visually distinguish- 
able to represent different types of components. Thus, 
they could for example be of different colours for differ- 
ent component types. 

In the preferred embodiment, each module com- 
prises a magnetic card reader and each data carrier 
comprises a magnetic swipe card. However, many other 
possibilities exist for the interaction between modules 
and data carriers. 

If each module could be arranged not only to read 
data from a data carrier, but also to write data to it, then 
it would be possible for each module to comprise a pro- 
grammed microcontroller which is capable of reading 
the unique identification from the data carrier, and mod- 
ifying or storing data onto the data carrier to indicate its 
status and its sequence of processes. 

For a better understanding of the present invention 
and to show how the same may be carried into effect 
reference will now be made by way of example to the 
accompanying drawings in which: 

Figure la illustrates the interconnected compo- 
nents of a system for simulating a production proc- 
ess, with the solid black lines indicating electrical 
connections; 

Figure 1b illustrates the movement of data carriers 
from reading module to reading module in the sys- 
tem of Figure la, with the arrows indicating direction 
of movement of components; 
Figure 2 illustrates a data carrier suitable for use in 
the system of Figure 1; 

Figure 3a illustrates a reading module suitable for 
use in the system of Figure 1, which can read the 
data carrier illustrated in Figure 2; 
Figure 3b illustrates the circuitry of the reading mod- 
ule illustrated in Figure 3a; 

Figures 4a to 4e illustrate various databases stored 
on the computer of the system illustrated in Figure 
1; and 

Figure 5 is a flow chart of the proc dural st ps in 
the simulation ol a process step in the process sim- 
ulated by the system illustrated in Figure 1 . 



A general concept underlying th described syst m 
is that a process flow in a production environment can 
be reduced to a number of distinct process steps, where 
each process step acts on a component. As compo- 

5 nents pass through the process steps they become in- 
spected, modified or treated components depending on 
the individual process step. The process steps for each 
type of component have to be applied to the component 
in a particular sequence which is termed herein a job 

w route. Each of the steps in the process flow is represent- 
ed by a data carrier reader. The data carrier readers are 
all connected to a controller which controls the simula- 
tion. Data carriers are used to represent the compo- 
nents as they progress through the steps of the process 

is flow. A single data carrier may therefore start as repre- 
senting an untreated component at the beginning of a 
process flow, and after successfully passing though the 
reading devices representing the successive steps in 
the process flow the data carrier will represent a fin- 

20 ished, properly treated output product of the process 
" flow. An attempted transaction between a data carrier 
and a reader takes place when the user wishes the com- 
ponent represented by a particular data carrier to be 
subject to the process step represented by a particular 

2S data carrier reader. A valid transaction occurs when, in 
the simulation, the particular component represented by 
the data carrier can validly be subjected to the particular 
process step represented by the data carrier reader at 
that time. The controller records that the data carrier is 

so now "locked" at that particular process step, and pre- 
vents it being part of a valid transaction with another da- 
ta carrier reader until the controller has determined after 
a determined period has passed that the particular proc- 
ess step has finished and the data carrier now repre- 
ss sents a treated component which is "unlocked". The da- 
ta carrier can now enter into a valid transaction with the 
data carrier reader which represents the next step in the 
process flow. The controller determines the period for a 
particular process to finish in accordance with the char- 

40 acteristics of the process step being simulated. The de- 
termination may be influenced by strategic or tactical de- 
cisions taken by the user. The controller also determines 
whether or not an attempted transaction is valid based 
on the preassigned job route for that component. 
45 Reference will now be made to Figures la to 5 which 
illustrate one particular example of how a production 
process for the production of bicycles may be simulated. 
In these figures, similar reference numerals denote sim- 
ilar parts. 

so in this example a bicycle is made from the following 
components: handlebars, saddle; chain, two whe Is 
and a frame. The handlebars, saddle, chain and wheels 
are purchased from an external supplier and may be 
stored on-site, whereas the frame is manufactured on- 

55 site from lengths of metal tubing. The components of the 
bicycle are then assembled to create the finished prod- 
uct which is dispatched to the customer. The whole pro- 
duction process can be divided into three process flows: 
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a) the storage of handlebars, saddle, chain and 
wheels; 

b) the manufacture of a frame; and 

c) the assembly and dispatch of a bicycle. 

The simulation of process flow a) - the storage of 
components - consists of the process steps: 



1 ) receipt of the separate components; 

2) inspection of the components which is optional; 
and 

3) storage. 

The simulation of process flow b) - the manufacture 
of a frame - consists of the process steps: 

1) receiving metal tubing; 

2) sawing the metal tubing; 

3) milling the ends of the cut tubes; 

4) drilling the tubing; 

5) welding the tubing together using awelding ro- 
bot; 

6) painting the frame; and 

7) inspecting the frame, which is optional 

The simulation of process flow c) - the assembly 
and dispatch of the bicycles - consists of the following 
steps: 

1) assembly of the components; and 

2) dispatch of assembled bicycles. 

The system for simulating the production of a bicy- 
cle is set up as illustrated in Figure la. Each of the read- 
ing modules, 200,202,204,206 ... 220 are serially inter- 
connected by the electrical interconnects 
504,506,508 ... 522. The first reading module 200 in the 
interconnected series of reading modules is connected 
to a gateway module 300 by an electrical interconnect 
502 and the gateway module 300 is, in turn, connected 
to a computer 400 by an electrical interconnect 500. A 
second computer 402 may be connected to the gateway 
module 300 by an electrical interconnect 524. The var- 
ious reading modules in this example are all identical 
and they are releasably interconnected to one another 
by the interconnects. The reading modules 200-220 are 
further described in relation to Figures 3a and 3b. The 
gateway module 300 incorporates a LON chip to provide 
local intelligence. Communication between the reading 
modules 200-220 along interconnects 504-522 and be- 
tween the reading module 200 and the gateway module 
300 along interconnect 502, is by way of LON Protocol 
Serial Communications. Communication between the 
gateway module 300 and the host computer 400 on in- 
t rconnect 500 is by way of RS 232 Serial Communica- 
tions. 

Each of th reading modules 200-220 represents a 
process step in one of the process flows a-c. The steps 



1 ), 2) and 3) of process flow a) are repr sented respec- 
tively by reading modules 204, 202 and 200. The steps 
1) to 7) of process flow b) are represented respectively 
by reading modules 204-216. The steps 1) and 2) of 
s process flow c) are represented by reading modules 218 
and 220. 

The reading modules can read a unique identifica- 
tion in the form of a number encoded onto a magnetic 
strip carried by a data carrier in the form of a card as 

10 illustrated in Figure 2. The card 100 has a body 2 pref- 
erably made of plastic but which could also be made of 
any suitable material. The body 2 carries a magnetic 
strip 4. The magnetic strip 4 is encoded with a unique 
identification which may be read by any one of the read- 

is ing modules 200-220 illustrated in Figure 1. The card 
identification is an identification number which is record- 
ed onto the magnetic strip before the card is supplied to 
the customer. There are five distinct colours of cards of 
the type illustrated in Figure 2. One red card is used to 

20 represent one handlebar in a batch of five handlebars. 
One orange card represents one of a batch of five sad- 
dles. One yellow card represents one chain in a batch 
of five chains. One green card represents one wheel in 
a batch of ten wheels. One blue card represents a quan- 

2S tity of steel tubing sufficient to make five bicycles which 
much be received as an input to the process. To properly 
simulate the production environment it is intended that 
the red, orange, yellow and green cards pass through 
the sequence of reading modules 204,202,200, to sim- 

30 ulate the process flow a) and the blue cards pass 
through the sequence of reading modules 204-216 to 
simulate the process flow b). The cards then pass 
through reading module 218 where the five cards rep- 
resenting the components of the bicycle are exchanged 

25 for a single card representing the assembled bicycle. 
This single card passes from reading module 218 
through 220 to simulate the process flowc) . The direc- 
tion of movement of the cards through the reading mod- 
ules is illustrated in Figure 1b. 

40 The number of red, orange, yellow, green or blue 
cards there are active in the simulation at any one time 
will depend upon what and how many bicycle compo- 
nents the user has purchased from suppliers and upon 
how many bicycles are being produced. The user deter- 

45 mines which components are needed to build a bicycle. 
A Supplier List as illustrated in fig 4c describes which 
supplier produces which components and details how 
reliable the components are and how much they cost. 
The user then buys the necessary components by issu- 

50 ing a 'Purchaser Order 1 to the supplierthrough the com- 
puter. The user then awaits the simulated arrival of the 
components from the supplier on the computer and con- 
tinues to manage the production unit simulated by the 
system with the compon nts which have already ar- 

55 rived. When a new compon nt is d livered from a sup- 
plier as indicated by the comput r a card representing 
the component must be entered into the simulation. 
When a card enters into the simulation it is swiped 
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through the "goods in" reading module 204. The reading 
module 204 reads the card's unique identification. The 
computer 400 associates with the card's identification 
number a number of attributes related to the component 
the card represents. These attributes are stored in a 
number of databases in the computer. The attributes 
comprise fields which do not change during the course 
of a simulation and fields which van/ during the course 
of a simulation, as will be described later. 

Figure 3a illustrates the reading module 208 illus- 
trated in Figures 1a and 1b, which is suitable for use in 
the present embodiment. The reading module has con- 
nectors 28 and 26 for receiving respectively intercon- 
nects 510 and 512. The interconnects are detachable 
from the connectors 26 and 28. The reading machine 
208 has a groove 18, through which a card may be 
swiped. Swiping a card 100 through the groove exposes 
the magnetic strip 4 on the card to card reading circuitry 
within the module 208. The reading module 208 has 
three separate indicating lights 10,12 and 14 which in- 
dicate the status of the module within the simulation. 
The "working" light 14 is illuminated to indicate that the 
reading module is currently engaged in implementing a 
process step on a component. The "idle" light 12 is illu- 
minated to indicate to a user that the reading module 
represents a process step that is currently awaiting a 
component and is intended to prompt the user to supply 
a component to the process step by swiping an appro- 
priate card through the groove 18. The "failed" light 10 
is illuminated to indicate that the reading module repre- 
sents a process step in the simulation which is unable 
to be effected because the apparatus for carrying out 
the process step represented by the reading module 
208 is simulating a machine or process which is inoper- 
ative. The LCD 16 displays the process step which the 
reading module represents in the simulation. In this ex- 
ample the reading module 208 represents the process 
step carried out by the milling machine. The LCD also 
illustrates how long the milling process will be engaged 
in processing the components represented by the 
swiped card (or cards). In this example the milling ma- 
chine will be actively employed for a total ol twelve hours 
of simulation time. The loudspeaker 24 is used to signal 
to the user whether a transaction between a reading 
module and a card is a valid transaction. The reset but- 
ton 20 is used to reset the reading module 208. The re- 
cess 22 in the body of the reading module 208 is used 
to store cards after they have been involved in a valid 
transaction with the reading module 208. 

Figure 3b illustrates a schematic circuit diagram of 
the reading module 208. The module controller 32 com- 
prises a LON chip and memory 34. The controller 32 is 
connected to other modules through interconnects 510 
and 512 and ultimately through a chain of subs quent 
modules and interconnects to the host computer. The 
controller receives an input from card reading circuitry 
30 along signal line 41 and an input from reset button 
20 along signal line 42. The controller controls the LCD 



16, the speaker 24 and th lights 10,12 and 14 through 
respective signal lines 43,44,45,46 and 47. Reference 
numeral 36 indicates a clock. This clock is used by the 
controller 32 during the simulation to determine when a 
s simulated process step has been completed according 
to the allotted time period in simulated time. 

After physically interconnecting the reading mod- 
ules, the gateway module and the computer as illustrat- 
ed in Figure la, the data for simulating the production 
10 process is stored on the computer. The data is stored 
as a series of databases. A typical portion of one such 
database is illustrated in Figure 4a. This is part of the 
"Parts List" database which has six distinct input fields: 
"Identification Number*; "Component"; "Supplier"; "Last 
is Module"; "Status" and "Condition". 

The "Identification Number" field receives and 
stores the identification number of each ol the cards 1 00 
which are active in the simulation. Each row in the da- 
tabase in the remaining five fields records specific at- 
20 tributes assigned by the simulation to the particular card 
1 00 which carries the identification number stored in the 
"Identification Number" field in that row. 

The "Component" field records which type of com- 
ponent each of the cards 100 represent in the simula- 
2S tion. In the present case the possible inputs to this field 
are saddle (S), handlebars (H), chain (C), wheels (W) 
and tubing (T). The card which represents tubing will 
travel through the process modules 204-216 to simulate 
the process flow b). At the end of the process flow th 
30 output from the process step represented by reading 
module 216 is a batch of frames. However, the cards 
which represent such frames, will still have an entry in 
the "Parts List" database which records tubing (T) in the 
"Component" field. The progression of the component 
35 through the various steps of the process flow is recorded 
in the "Last Module" and "Status" fields. 

The "Supplier" field records the supplier from whom 
the component represented by each of the cards 100 
was purchased. 
40 The "Identification Number", "Component" and 
"Supplier" fields receive inputs at the initiation of the sim- 
ulation. The simulation does not thenceforth vary the in- 
puts to these fields. 

The "Last Module" field records for each one of the 
46 cards represented by an input in the "Identification 
Number" field, the reading module with which that card 
last completed a valid transaction. In the present exam- 
ple each of the reading modules are identified by the 
re f erence numeral used in relation to Figure la. 
so The "Status" field records an input LOCKED or 
FREE. The FREE input is recorded against a particular 
identification number when, in the simulation, the proc- 
ess step represented by the module with which the card 
with that particular identification number last had a valid 
55 transaction has finish d. Th LOCKED input is recorded 
against a particular id ntification number when the card 
with that particular identification number has been sub- 
ject to a valid transaction with a reading module, and is 
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still, according to simulated time, involved in that proc- 
ess. 

The "Condition" field records whether, in the simu- 
lation, the component represented by a particular card 
is sub-standard. If it is, a FAILED input is recorded in 
this field against the identification number of the card 
which represents the sub-standard component. 

The "Last Module", "Status" and "Condition" fields 
are fields whose inputs are varied by the computer in 
the course of a simulation. 

A typical portion of another database is illustrated 
in Figure 4b. This is part of the "Job Route for Compo- 
nent T" database, which has three distinct fields: "Mod- 
ule Code"; "Process time"; "Transit time". 

The "Module Code" field records the sequence of 
the process steps in a process flow. Each process step 
is represented by a reading module. Each reading mod- 
ule is represented by its identifier, which in this example 
is the reference numeral used to refer to that module in 
Figure la. The sequence progresses down the page. 
The sequence of reading modules represented by the 
illustration in Figure 4b is the sequence of reading mod- 
ules which a card having a "component" field entry in 
the Parts List database of "T" must validly transact with, 
before that card can represent a finished frame in the 
simulation. The sequence is a job route for all compo- 
nents of type "T". The computer associates each step 
in the process with a reading module identifier during 
set up of the simulation. 

The "Process Time" field records the ideal simula- 
tion time each of the process steps in the process flow 
takes to treat the particular component or batch of com- 
ponents subjected to that process. 

The "Transmit Time" field records against each of 
the process steps in the process flow, how long in sim- 
ulation time it would take for the component treated by 
the preceding process step to be transferred to that 
process step. 

A job route database exists for each of the compo- 
nent types: handlebars (H), saddle (S), chain (C), 
wheels (W) and tubing (T). 

The production process simulated by the system il- 
lustrated in Figure la comprises a number of distinct 
process flows and each process flow comprises a 
number of distinct steps. It will now be explained how 
the whole production process can be simulated. 

Each card represents in the simulation a compo- 
nent or batch of components. Each reading module rep- 
resents in the simulation a process step in a process 
flow. The swiping of a card through a card reader rep- 
resents the desire of the user to have the component 
represented by the card to be treated by the process 
step represented by the card reader. A valid transaction 
occurs when the card r presents a valid input to the 
process step repr sent d by the reading module. A 
transaction could be invalid for a number ol reasons. For 
example, the component could be an unsuitable com- 
ponent for that process, it could be "locked" (involved in 



another process) or an attempt is being made to pres nt 
the component to a process step out of the intended se- 
quence. When a card has been subject to a valid trans- 
action with a particular reading module, the card will not 

5 becapable ofvalidly transactin g with other reading mod- 
ules for a simulated period. The particular reading mod- 
ule simulates the process step in the process flow that 
it represents, and on the completion of that simulated 
process step it updates the databases held on the com- 

io puter so that the card now represents a component 
treated according to the process step. The card now be- 
comes FREE and is able to validly transact with another 
reading module. 

The time taken for a reading module to simulate the 

ts process step in the process flow it represents, can be 
varied responsive to strategic or tactical decisions taken 
by the user. 

The particulars of the simulation of a process step 
will now be exemplified with reference to Figure 5. 

20 When a card 1 00 is swiped through a reading mod- 
ule 200-220, the reading circuitry 30 of the module reads 
the identification number recorded on the magnetic strip 
4 of the card 100. 

The reading module then transmits to the computer 

2S 400 a signal along the interconnects 500-522, which in- 
cludes both the identification number of the card that 
has been swiped and the identifier of the reading module 
which has swiped the card. 

The computer then determines whether the card 

30 represents a component within the simulation. The com- 
puter inspects the "Identification Number" field of the 
"Parts List" database. 

If the computer finds an input in this field which cor- 
responds to the read identification number it then deter- 

35 mines that the association of the card and the reading 
module represents a component in the simulation. If the 
computer does not find an input in the field which corre- 
sponds to the read identification number it determines 
that the card does not represent a component in the sim- 

40 ulation. The computer then sends a signal back to the 
reading module indicating that the card is not part of the 
simulation. The controller 32 sends a signal along signal 
line 44 to speaker 24 which emits an audible sound in- 
dicating that the card has not been accepted. The rea- 

45 son for the non-acceptance of the transaction may be 
displayed on a screen of the computer 400 or on the 
LCD 16 of the reading module. The computer does not 
proceed further in this instance, and awaits the next 
transaction. 

50 it the card does represent a component in the sim- 
ulation, the computer proceeds to determine whether 
the association of the particular card with the particular 
module represents a valid transaction. The entries 
made in respect of the identification numb r of the card 

55 in the Parts List database are inspected. If th "Status" 
field has an entry LOCKED, the card represents a com- 
ponent which has already been input into a process step 
and that process step has not yet finished. The card is 
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not therefore valid. The computer sends a signal back 
to the reading module indicating that the card is not val- 
id. The controller 32 sends a signal along signal line 44 
to the speaker 24 which emits an audible sound indicat- 
ing that the card is invalid. The reason tor the invalidity 
of the card may be displayed on a screen of the compu- 
ter 400 or on the LCD 16 of the reading module. The 
computer does not proceed further in this instance and 
awaits a further transaction. 

If the •Status'' field has an entry FREE the card is 
valid and the computer proceeds to determine whether 
the process step represented by the reading module is 
a valid process for the component represented by the 
card. The Parts List database is inspected by the com- 
puter and the "Component" field and "Last Module" field 
are read 1or the entries corresponding to the identifica- 
tion number of the card 100. We shall assume for the 
purposes of illustration that the entry in the "Component" 
field is T" and the entry in the "Last Module" field is 
"206". The Job Route database lor the component cor- 
responding to the entry in the "Component" field is ac- 
cessed, in this example the Job Route database for 
component "TV The "module code" corresponding to the 
entry in the "Last Module" field is accessed and the sub- 
sequent entry in the job route is read. In this example, 
the entry in the "Last Module" field is "206" and the sub- 
sequent entry in the job route is 208 (see Figure 4b). If 
the entry read from the job route corresponds to the 
identifier received from the reading module subsequent 
to its transaction with the card, then the process step 
represented by the module is a valid process step. If the 
entry read from the job route does not correspond to the 
identifier received from the reading module it signifies 
that the card has been read through the wrong reading 
module. -If the process step is not valid, the computer 
sends a signal back to the reading module indicating 
that the process step is not valid. The controller 32 
sends a signal along line 44 to the speaker 24 which 
emits an audible sound indicating that the process step 
is invalid. The reason for the invalidity of the process 
step may be displayed on a screen of the computer 400 
or on the LCD 16 of the reading module. The computer 
does not proceed further in this instance and awaits a 
further transaction. If the process step is valid then the 
transaction between the card and the reading module is 
valid. 

Having established that the transaction between 
the card and reading module is valid, the computer up- 
dates the "Parts List" database. The entry in the "Status" 
field corresponding to the identification number of the 
swiped card is updated from FREE to LOCKED. The en- 
try on the "Last Module" field corresponding to the iden- 
tification number of the swiped card is updated to record 
the identifier of the reading module with which the card 
has just validly transacted. The computer also s nds a 
signal back to the reading modul indicating that the 
transaction is valid. The controller 32 sends a signal 
along lin 44 to the speaker 24 which emits an audible 
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sound indicating that the transaction is valid. Th com- 
puter also sends control data to the controller 32 of the 
reading module. This control data is stored in memory 
34 by the controller 32 of the reading module in associ- 
5 ation with the identification number of the card. The data 
is used to calculate the total simulated duration of the 
process step represented by the valid transaction be- 
tween the_card and the reading module. 

The reading module simulates the processing of the 
io components represented by cards in the order in which 
the cards have validly transacted with the reading mod- 
ule. It is possible to swipe a number of cards through a 
reading module and create a backlog of components in- 
put to that reading module in the simulation. The com- 
75 ponents represented by the cards effectively form a 
queue, in the simulation, at the input to the process step 
represented by the reading module. If it is found neces- 
sary to change the order in which the components are 
processed the reading module is reset by depressing 
20 the reset button 20. The reset button allows the user to 
"unload" cards previously loaded onto a process but still 
awaiting processing. This action causes the controller 
to instruct the computer to reset the fields in the Parts 
List database, associated with the cards in the backlog 
2S to their preswipe condition. The reading module com- 
pletes the component it is currently working on befor 
changing to its unloaded state. 

When it is the turn of one of the components in th 
queue of the process step to be processed, the control 
30 data stored in memory 34 by the controller 32 associat- 
ed with the identification number ol the card which rep- 
resents that component is retrieved from memory 34 by 
controller 32. The controller then calculates the simula- 
tion time for the processing of this component. A simu- 
35 lation of the processing of the component is initiated - 
the clock 36 of controller 32 counts down the simulation 
time and the controller 32 illuminates the light 1 4 through 
signal line 47. At the end of the simulation time the con- 
troller 32 of the reading module instructs the computer 
40 to change the "Status" field in the "Parts List" database 
associated with the card identification number from 
LOCKED to FREE. The reading module then loads the 
next component in its input queue and if there are no 
components waiting to be received the controller deac- 
45 tivates the light 14 and activates the light 1 2. The read- 
ing module is then in its unloaded state. 

The calculation of the total simulated duration of the 
process step, is, at its simplest, calculated from the in- 
formation in the job route database for the compon nt. 
so The entries for the "Process Time" field and the "Transit 
Time" field, for the particular reading module are 
summed to obtain the standard total simulation tim for 
the processing of that component by the process step 
represented by the reading module. The controller 32 of 
55 the reading module may how ver vary the standard total 
time using a resident program, to create an actual total 
simulation time different from the standard total simula- 
tion time. 
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The variation of the actual total simulation time from 
the standard total simulation time is calculated on the 
basis of information stored in the computer. This infor- 
mation may include the operator training level, morale, 
experience etc or other factors which may effect the 5 
speed of execution of a particular process step. This in- 
formation can in turn be made dependent upon the stra- 
tegic or tactical decisions made by the user in setting up 
the simulation, for example the level of pay for the op- 
erator or the investment in training. The information re- 
quired for this calculation is supplied by the computer to 
the controller of the reading module as part of the control 
data. This data is stored locally in memory 34. Such data 
may include an Employee List database as illustrated in 
Figure 4d and a Machinery List database as illustrated 
in Figure 4e. In particular the resident program will use 
the information relating to a machine and the machine's 
operator to calculate if and by how much the actual total 
simulation time should exceed the standard total simu- 
lation time. 

The above stages in the simulation of a process 
step can conveniently be divided into: 

a) Ascertaining whether the card represents a com- 
ponent in the simulation. 

b) Ascertaining whether the card is valid i.e. wheth- 
er its status is FREE. 

c) Ascertaining whether the reading module repre- 
sents a process step which is a valid process step 
for the component represented by the card. 

d) Initiation of the simulation, if the card/module 
transaction is valid, comprising: 

(i) updating "Status'' field in Parts List 

(ii) updating "Last Module" field in Parts List 

(iii) providing signals and control data to the 
module 

e) Simulation of the process step by the reading 
module. 

f) Termination of the process step which comprises: 

(i) updating "Status" field in Parts List 

(ii) updating the "Condition" field in Parts List. 

The above particular description of these stages in 
the simulation related to the simulation of a process step 
which must follow a particular preceding step and in 
which the number of components received as an input 
is conserved at the output. The simulation system is 
however more flexibl than this, and can simulate fur- 
ther process steps for example ones which are optional, 
which receive multiple components as an input and pro- 
duce a single output and which r ceive a single compo- 



nent as an input and produce multiple outputs. 

The particulars of the simulation of an optional proc- 
ess step will now be exemplified. The simulation pro- 
ceeds through stages a) to f) above, however there are 
particular differences in the implementation of stages c) 
and d). If the process step is optional then the reading 
module which represents that optional process step will, 
on transacting .with a card, produce an identifier which 
by default represents a valid process step. The identifier 
to of the reading module representing the optional process 
step will not appear in the job route of any component. 
At stage d) (the initiation of the simulation), the updating 
1 of the "Last Module" field in the Parts List will not occur. 
An example of an optional process step in process flow 
is a) is the process step represented by reading module 
202 i.e. goods inspection. The inspection step repre- 
sented by reading module 216, is also optional. 

The particulars of the simulation of a process step 
which receives multiple components and produces a 
20 single component will now be exemplified. The opera- 
tion of the simulation will be explained in relation to the 
'assembly' process step represented by reading module 
218. The assembly process step receives four distinct 
types of components from process flow a), namely han- 
2S dlebars represented by a red card, a saddle represented 
by an orange card, a chain represented by a yellow card 
and two wheels represented by two green cards. It also 
receives a frame represented by a blue card from proc- 
ess flow b). In the simulation these components are 
30 combined to produce an assembled bicycle which is 
represented by a mauve card. The mauve card replaces 
the red, orange, yellow, green and blue cards. The com- 
ponents are combined by swiping all of the five cards 
representing the components of the bicycle through the 
35 reading module. Stages a) to c) of the simulation are 
carried out for each card. The module now requests a 
new mauve card. The user swipes this card through the 
reading module. The five component cards are then re- 
moved from the simulation by deleting their entries from 
40 the "Parts List" databases. The new card is added to the 
"Parts List" database. If any of the 5 components had a 
FAILED condition then the condition of the assembled 
~ bicycle which is represented by the mauve card is re- 
corded as FAILED. Stages d), e) and f) of the simulation 
45 then continue. It is the entries in the database associat- 
ed with the new mauve card which are updated. The 
mauve card then continues through process flow c). 

The particulars of a process step which receives a 
single component and produces multiple components 
50 w i|| now be exemplified. In this situation a user swip s 
a single card through the reading module. Stages a), b) 
and c) of the simulation are carried out. The reading 
module will then request the user toswipe multiple cards 
through the r ading modul . The databas will be 
55 amended to update the changes. The entry for th orig- 
inal single component will be removed and entries for 
the new multiple components will be mad . 

The simulation system can also simulate the failure 
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of a component or a machine in a process step. A com- 
ponent is failed by changing the "Condition" field for the 
identification number of the card which represents that 
component, in the "Parts List" database. The compo- 
nent represented by the card is now considered to be 
defective by the simulation. However, the failure of the 
component is only revealed to the user if an inspection 
process is performed by the user. The inspection proc- 
ess can be implemented either by a separate reading 
module such as reading module 216 in Figure 1 or by 
adding an inspection process and additional simulation 
time to any one of the process steps in the process. In- 
spection processes will typically be optional. When an 
inspection process is performed and the card read by 
the reading module represents a failed component, the 
computer sends a signal to the controller 32 of the read- 
ing module which causes the speaker 24 to produce an 
audible signal indicating the component has tailed. The 
fact that the card represents failed components may be 
displayed on the LCD 16 of the reading module or the 
screen of the computer 400. The failure of a component 
is effected by a program resident in the controller 32 of 
the reading module. The program calculates the proba- 
bility that the component being processed by the proc- 
ess step represented by the reading module is defec- 
tive. The calculation is made on the basis of information 
stored in the computer. This information may include the 
reliability of the components received from particular 
suppliers or the likelihood that a process step will mal- 
function and fail the component. This information can in 
turn be made dependent upon the strategic or tactical 
decisions made by the user in setting up the simulation, 
for example the choice of supplier or the choice of ma- 
chinery and employee to work the machinery respec- 
tively. The information required for this calculation is 
supplied by the computer to the controller of the reading 
module as part of the control data. This data is stored 
locally in the memory 34. Such data may include the 
Supplier List database illustrated in Figure 4c, the Ma- 
chinery List database illustrated in Figure 4e and the 
Employee List database illustrated in Figure 4d. In these 
examples the program will calculate the likelihood of fail- 
ure on the basis of the relevant entries in the "Quality 
Coef" field and "Last Service" field ot the Supplier List 
and Machinery List databases respectively, and on the 
basis of operator attributes as stored in the Employee 
List database. 

The simulation system can also simulate the failure 
of a machine in a process step. The failure of a process 
step in the simulation is effected by a program resident 
in the controller 32 of the reading module. The program 
calculates the probability of the process step being in- 
terrupted by the failure of a machine within the process 
step. The calculation is mad on the basis of information 
stored on the computer. This information may include 
the type of machines employed in the process flow and 
the skill of the employees operating the machines. This 
information can be made dependent upon the strategic 



or tactical decisions made by the user in setting up th 
simulation, for example the choice of employee, ma- 
chine type and service schedule. The information re- 
quired for this calculation is supplied by the computer to 
5 the controller of the reading module as part of the control 
data. Such data may include an Employee List database 
as illustrated in Figure 4d and Machinery List database 
as illustrated in Figure 4e. The failure of a process step 
is recorded in the "Condition" field of the Machinery List 
10 database. The information is stored locally in the mem- 
ory 34. The simulated failure of the process step will 
cause the controller 32 to halt its simulation of the proc- 
ess step. The controller will illuminate light 10 on the 
reading module associated with the process step and 
is disable lights 1 4 and 1 2. The reading module will be dis- 
abled and will not appear to transact with cards swiped 
through it. The reading module can be reinstated into 
the simulation by performing a simulated service on the 
machines in the process step. Reinstatement can occur 
20 either through the computer or through a "service card" 
which is swiped through the module. The reinstatement 
will have some cost to the user within the simulation. On 
reinstatement of the reading module the light 10 is de- 
activated and the controller proceeds to simulate the 
25 process step which was halted. 

Each of the reading modules have a clock for re- 
cording the simulation time. The simulation time of each 
of the reading modules is synchronised at the start of 
the simulation and each reading module runs its simu- 
30 lation time at the same rate with respect to real time. For 
example each hour of simulation time may be ten min- 
utes of real time. The relationship between real time and 
simulated time can be controlled by a user so that sim- 
ulated time can be slowed down or speeded up or 
35 stopped altogether. 

A supervisor of the simulation can access the data 
stored on computer 400 and change the information 
stored there. In particular the supervisor could change 
an entry in any of the databases illustrated in Figures 
40 4a-4e, and thereby, for example, effect a change in the 
throughput of a process step in the process or a change 
in the quality of goods supplied by a supplier. In the sys- 
tem illustrated in Figure 1 the supervisor accesses the 
relevant data through computer 402. 
45 Although in the specific example given, each card 
represents a single component, it would be possible for 
a single card to represent a batch or set of components. 
In this connection, a component could represent a quan- 
tity of stock or material to be divided into a plurality of 
50 smaller components, for example a batch of sheet ste I 
to be cut into individual parts. 

Although in the described example a different colour 
of card is used to represent each type of component, in 
another embodiment a card with a re-writable text panel 
55 is us d. The text pan I allows the identity of the compo- 
nent represented by the card to be visually discerned. 
In addition a spac is provided for hand written notes to 
be made to the card using an erasable marker pen. A 
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card writer, connected to the host computer is used to 
write a text message on the card identifying the compo- 
nent type. The system may be laid out on a base to cre- 
ate a model factory. The base in one embodiment is 
formed from a white board, that is a board which can be 
erasably written to. A marker can be used to mark out 
the physical boundaries of the factory and to make notes 
on the base. A number of bus bars, or tracks on the white 
board are used as the interconnects 502 to 522. 

The computer provides a menu led instruction for 
setting up different simulations. The set up procedure 
includes the identification of the process to be simulat- 
ed, the identification of the separate process steps in 
that process, the association of a reading module with 
each process step by associating the modules identifier 
with that process step within the host computer, the 
identification of the components required to perform the 
simulation, and the creation of the components by using 
the card writer to visually identify a card as a component 
in the simulation and by associating the card's identifi- 
cation number with that component in the computer. 



Claims 

1. A system for simulating a production environment 
in which a plurality of components are subject to a 
plurality of different processes to generate an end 
product, the system comprising: 

a plurality of modules, each module represent- 
ing one of said processes and comprising read 
circuitry for reading data from a data carrier and 
means for providing an indication representing 
whether an attempted transaction of the mod- 
ule is valid or invalid based on a predetermined 
job route which defines a valid predetermined 
sequence and timing of processes for each 
component or set of components; and 
a set of such data carriers representing said 
components and each carrying a unique iden- 
tification which can be read by the read circuitry 
and which represents a component or a set of 
components. 

2. A system according to claim 1 , wherein each com- 
ponent or set of components is occupied for a pre- 
determined period associated with each process, 
and wherein a locked status is allocated to the 
unique identification of a data carrier representing 
an occupied component when a valid transaction 
has been effected. 

3. A system according to claim 2, in which each mod- 
ule has a tim r for monitoring said predet rmin d 
period associated with the process it is represent- 
ing. 



4. A system according to claim 2 or 3, comprising a 
system clock which provides a visual indication of 
simulated time in which said predetermined periods 
are measured. 

5 

5. A system according to any preceding claim, which 
comprises a database holding each said unique 
identification in association with the type of compo- 
nent it represents and its current status. 

10 

6. A system according to any preceding claim which 
comprises a controller connected to each of the plu- 
rality of modules and operable to determine the va- 
lidity of an attempted transaction. 

15 

7. A system according to any preceding claim wherein 
each module comprises means for providing a vis- 
ual indication of its status as idle, working or failed. 

20 8. A system according to any preceding claim, com- 
prising a display for displaying the indication of a 
valid/non-valid transaction. 

9. A system according to claim 6, which comprises a 
2S gateway module connected to a communication 

path of each module for providing an interface be- 
tween the modules and the controller. 

10. A system according to any preceding claim which 
30 comprises an initiator for allocating to each module 

a process it is to represent with a predetermined pe- 
riod associated therewith during which a compo- 
nent would be occupied. 

35 11. A system according to claim 10 wherein the initiator 
also allocates to each unique identification a com- 
ponent and a predetermined sequence of process- 
es for that component. 

40 12. A system according to any preceding claim wherein 
the data carriers are usually distinguishable to rep- 
resent different types of component. 
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